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Abstract 

The lambda calculus, subject to typing restrictions, provides a syn- 
tax for the internal language of cartesian closed categories. This pa- 
per establishes a parallel result: staging annotations [? ], subject to 
named level restrictions, provide a syntax for the internal language 
of Freyd categories, which are known to be in bijective correspon- 
dence with Arrows. The connection is made by interpreting multi- 
stage type systems as indexed functors from polynomial categories 
to their reindexings (Definitions 16 and 17). 

This result applies only to multi-stage languages which are (1) ho- 
mogeneous, (2) allow cross-stage persistence and (3) place no re- 
strictions on the use of structural rules in typing derivations. Re- 
moving these restrictions and repeating the construction yields gen- 
eralized arrows, of which Arrows are a particular case. A transla- 
tion from well-typed multi-stage programs to single-stage GArrow 
terms is provided. The translation is defined by induction on the 
structure of the proof that the multi-stage program is well-typed, re- 
lying on information encoded in the proof's use of structural rules 
(weakening, contraction, exchange, and context associativity). 

Metalanguage designers can now factor out the syntactic machinery 
of metaprogramming by providing a single translation from staging 
syntax into expressions of generalized arrow type. Object language 
providers need only implement the functions of the generalized ar- 
row type class in point-free style. Object language users may write 
metaprograms over these object languages in a point-ful style, us- 
ing the same binding, scoping, abstraction, and application mecha- 
nisms in both the object language and metalanguage. 

This paper's principal contributions are the GArrow definition of 
Figures 2 and 3, the translation in Figure 5 and the 
category-theoretic semantics of Definition 16. An accompanying 
Coq proof formalizes the type system, translation procedure, and 
key theorems. 



[Copyright notice will appear here once 'preprint' option is removed.] 



1. Introduction 



Metaprogramming, the practice of writing programs which con- 
struct and manipulate other programs, has a long history in the 
computing literature. However, prior to [? ] little of it dealt with 
metaprogramming in a statically typed setting where one wants to 
ensure not only that "well typed programs do not go wrong," but 
also that well typed metaprograms do not produce ill-typed object 
programs. 

One of the most popular applications of statically typed metapro- 
gramming has been the use of monads to account for different no- 
tions of computation [? ] as the impure programs manipulated by 
pure functions in a category equipped with a Kleisli triple. The 
use of monads in functional programming was later generalized 
to Arrows by Hughes, who writes "every time we sequence two 
monadic computations, we have an opportunity to run arbitrary 
code in between them. [? ]" Arrows curtail this freedom, permit- 
ting the inclusion of static information. In practice, this has made 
Arrows a popular framework for metaprogramming, particularly 
when one is allowed to do things with object programs other than 
run them. 



Because adding a new object language involves nothing more than 
implementing the functions required by the Arrow type class, this 
approach to embedding makes it quite easy to provide new object 
languages. Although all embedded languages share a common syn- 
tax [? ], this syntax is profoundly different from that of the meta- 
language, which can make it difficult to use object languages. 



By contrast, staging annotations [? ] embed an object language 
within the metalanguage using the same binding, scoping, abstrac- 
tion, and application mechanisms as the metalanguage. However, 
the type system of the metalanguage must reflect the type system 
of the object language, so adding a new object language is quite 
difficult and generally requires making modifications to the meta- 
language compiler. 



This paper will use, as a running example, the pow function which 
has become ubiquitous in the metaprogramming literature. Here is 
the pow program written using Arrow notation [? ]: 
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Class Arrow 

((->) :Set->Set->Set) := 



Class GArrow ((**): Set->Set->Set) 

((->) :Set->Set->Set) := 



arr : (a->b) -> (a~>b) 

(»>) : a~>b -> b~>c -> a~>c 

first : a~>b -> (a*c)~>(b*c) 

(~~) : a~>b -> a~>b -> Prop 

pfl : Equivalence (a — b) 

pf2 : Morphism (a — b ==> b — c ==> a~~c) (»>) 

pf3 : Morphism (a — b ==> (a*c) — (b*c)) first 



id : a ~> a 

assoc : (a**b)**c ~> a**(b**c) 

cossa : a**(b**c) ~> (a**b)**c 

copy : a ~> a**a 

drop : a**b ~> a 

swap : a**b ~> b**a 

(»>) : a~>b -> b~>c -> a~>c 

first : a~>b -> (a**c) ~> (b**c) 

(~~) : a~>b -> a~>b -> Prop 

pfl : Equivalence (a — b) 

pf2 : Morphism (a — b ==> b~~c ==> a — c) (»>) 

pf3 : Morphism (a — b ==> (a**c) — (b**c)) first 



Figure 1. Definition for the Arrow class. See also Remark 1. Figure 2. Definition for the GArrow class. See also Remark 1. 



pow n = 
if n==0 
then est 1 
else proc x -> 

do pow' <- (pow (n-1)) -< x 

result <- (*) -< (x, pow') 

returnA -< result 

Here is an equivalent program written using staging annotations: 

pow n x = 
if n==0 
then <[ 1 ]> 

else <[ ~x * ~(pow (n-1) x) ] > 

Section 2 reviews Arrows and introduces generalized arrows. 
Section 3 presents a grammar and type system for a simplified 
MetaML- style [? ] multi-stage programming language. Section 4 
provides a translation procedure which produces generalized 
arrow values from the typing derivations of well-typed multi-stage 
programs. Section 5 walks through a few example programs, and 
Section 6 formalizes the category-theoretic underpinnings of 
staging annotations. 



2. Arrows 

From a programmer's perspective, an Arrow is a type belonging to 
the Coq type class [? ] shown in Figure 1. Briefly, the members of 
the class are type operators (~>) which take two arguments, sup- 
plied along with a function arr which lifts arbitrary functions into 
Arrows, a function (»>) which composes Arrows, and a function 
first which lifts an Arrow on a given type to an Arrow on tuples 
with that type as the first coordinate and the identity operation on 
the second coordinate. The last four declarations define an equiv- 
alence relation ( — ) and require that (>») and first preserve 
it. 

Remark 1 To improve readability, the following elements of Coq 
syntax have been elided from the printed version of this paper: 
semicolons, curly braces, Notation clauses, Implicit 
Argument clauses, explicit instantiation of implicit arguments, 
and polymorphic type quantifiers (specifically, f orall occurring 



immediately after a colon). The complete Coq code, which 
includes the elided text, is available online 1 

2.1 Generalized Arrows (GArrows) 

The Coq declaration for the GArrow class is shown in Figure 2; 
the laws for GArrows can be found in Figure 3 using mathemati- 
cal notation, and in Figure 15 using Coq notation. Proofs of these 
propositions appear as obligations for any code attempting to cre- 
ate an instance of the GArrow class, providing machine-checked 
assurance that the laws are satisfied. 

Comparing the two declarations, one can see that GArrows general- 
ize Arrows in two ways: 

1. The arr constructor is omitted, and part of its functionality is 
restored via id, assoc, cossa, drop, copy, and swap. 

2. The methods of the Arrow class are specified in terms of tuple 
types, which are assumed to be full cartesian products. GArrows 
relax this restriction, assuming only that the tupling operator is 
a monoid. 

Parameterizing GArrow over an arbitrary (**) : Set->Set->Set 
operator rather than requiring the use of the cartesian product al- 
lows for more generality: while there is a straightforward func- 
tion of type (Va)a^(a,a), there is no total function of type 
(V(**) :Set->Set->Set)(Va)a— >(a**a). The weaker construct 
makes it possible to deny users the ability to form such functions 
where they are inappropriate. In particular, it prevents properties 
of the cartesian product from imposing unwanted properties upon 
object language contexts, as will be shown in Definition 16 and 
utilized in Section 5.2. 

Remark 2 The following Arrow laws from [? , Figure 1] have 
been omitted from GArrow because they serve only to regulate arr: 

arr(g of) — arr / »> arr g (10) 

first (arr /) = arr(/ X id) (11) 

first / »> arr (id X g) = arr (id X g) »> first / (12) 

However, (11) above does serve the same purpose as law (7) of 
Figure 3. 



http : //www . cs . berkeley . edu/~megacz/garrows/GArrow. v 
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id »> / — 


J 




/ »> id = 


£ 

J 


(2) 


(J >:>> 9) >» ft — 


/ >>y (9 >>y h ) 


\5) 


first (/»> g) = 


(first /) »> (first g) 


(4) 


first (first /) »> assoc = 


assoc »> first / 


(5) 


cossa = 


swap »> assoc »> swap 


(6) 


first / »> drop = 


drop »> / 


(7) 


swap »> swap = 


id 


(8) 


copy »> swap = 


copy 


(9) 



Figure 3. Generalized Arrow laws. The first five laws are taken 
from [? , Figure 1]. The sixth law defines cossa in terms of swap; 
this makes it a redundant operation (much like *** for Arrows), 
though Section 4.6 investigates variants which eschew swap, mak- 
ing cossa no longer redundant. The seventh law expresses the fact 
that first should not have side effects. The last two laws establish 
some straightforward properties of swap and copy. A Coq rendi- 
tion of these laws can be found in Figure 15. 



Theorem 1 Every Arrow is a GArrow prod, where prod is the 
cartesian product. 

Proof. Instance Arrows_are_GArrows in GArrow. v □ 



3. Staging Annotations 
3.1 Natural Deduction 

This section briefly reviews the structural rules for natural deduc- 
tion. A will denote derivations, E will denote propositions and T 
will denote contexts, where a context consists either of a single 
proposition or a pair of subcontexts: 

r ::= s | r,r 

Therefore contexts can be viewed as binary trees. 

Remark 3 Although logically quite conventional - the (•, •) 
construct is exactly logical conjunction - this choice is 
proof-theoretically nonstandard; contexts are usually handled as 
lists. However, the translation given in Section 4 is only valid for 
proof derivations which are completely explicit about every 
structural rule invocation. The positions of these invocations in the 
proof derivation carry information which is used by the translation. 

By representing contexts with binary trees rather than lists one can 
avoid introducing rules which implicitly rearrange the context. One 
example of such a rule is one which uses ellipsis to abbreviate a 
sequence of propositions: 

r, ...,x : t h E 

Another example is a rule which tacitly assumes that lists of hypo- 
theticals are identified up to associativity: 

ri,x : r,r 2 h E 

The first six rules of Figure 5 are the structural rules. They are allow 
all other rules to be in a form where any necessary assumptions 
appear as the leftmost child of the context. 



E ::=T | e : r n | firstClass(r, if) e ::=x | Xx.e | e[e\\ (e) | ~e 

T ::=E | r,T e ::= • | e,e 

r/ ::— level name x ::= expression variable 

ff ::= ■ | 7], ff t ::=t — > r | {t 11 } 

Figure 4. Grammar for a simple multi-stage language. 

Lemma 1 (Permutation of Contexts) If there is a proof terminating 
in the judgement 



rihEi 

and some proposition E2 appears as a leaf of Ti, then there is a 
proof terminating in the judgement 



s 2 ,r 2 h Ei 

where the leaves of E 2 , r 2 are a permutation of the leaves of Ti. 
Furthermore, there is an algorithm for transforming the first proof 
tree into the second. 

Proof, in permutation_of .contexts in GArrow . v □ 

3.2 Typing Rules for Staging Annotations 

The grammar for a simple multi-stage language can be found in 
Figure 4; the corresponding typing rules are in Figure 5. 

Remark 4 Special attention should be paid to the superscripts 
used to denote levels; a proposition e : r v attributes a type r to 
an expression e at a named level rj; the named level 77 is part of 
the proposition, not the type. Named levels do not appear as part of 
types except the code type {t v }, which include exactly one level as 
part of the type; this level is written inside the code-brackets. The 
mnemonic justification for this choice of syntax can be seen in the 
typing rules for Brak and Esc. 

The first nonstructural rule, FC, distinguishes types inhabited by 
first class values - those that can be arguments or return values 
of functions. Because firstClass(r— >r, ff) is underivable without 
additional rules, the type system as shown will prohibit first-class 
functions. However, this restriction can easily be lifted by simply 
adding another typing rule: 

firstClass(ri,?7) 
firstClass(r 2 , ff) 
firstClass(ri— s-r 2 , ff) 

The next two rules are the variable (Var) and abstraction (Lam) 
rules. Note that the Var rule is applicable only when the context 
contains exactly the assumption needed and no others. Any extrane- 
ous context elements must be explicitly removed using Weak; this 
will be significant in Section 4.6 which explores the possibility of 
removing the Weak rule. The Lam rule is standard, save for the ad- 
ditional firstClass(r^, ff) hypothesis; this ensures that abstractions 
over non-first-class values may not be formed. 

The App and App n+1 provide for n-ary function application via 
the e[e] production in the grammar. After typechecking is com- 
plete, this n-ary application can be syntactically expanded into n in- 
stances of (curried) 1-ary application - for example, e[ei, e 2 , e^, ■] 
becomes (((eei)e 2 )es). However, by having syntactic indication 
of the application arity available at typechecking time the type 
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RULE 


SYNTAX SEMANTICS 


Assoc 


r 1 ,(r 2 ,r 3 )hE = a 


(ri,r 2 ),r 3 hE = assoc »> A 


Cossa 


(r 1 ,r 2 ),r 3 hs = a 


Ti, (r 2 ,r 3 ) hE = cossa »> A 


Exch 


ri,r 2 hE = a 


r 2 ,Ti hE = swap »> A 


Exch2 


(r 1; r 2 ),r 3 hE = a 


(r 2 ,ri),r 3 hE = (first swap) »> A 


Weak 


Ti hE = A 


ri,r 2 hE = drop»>A 


Cont 


ri,rihE = a 


Ti hE = copy »> A 


FC 


firstClass(r, (77, ff)) 


firstClass((r"}, ff) 


Var 




x : t v \~x : t v —id 


Lam 


firstClass(T x , ff) 
x . T x , 1 re . T — Za 


T \-Xx.e : (tWt)" = A 


Appo 


firstClass(r, ff) 

r he : r n = A 


T he[-] : T n = A 


App„+i 


firstClass(ro, ff) 

7 X he x : (ro — > T x ) n = A^ 
To he : Tq = A 
x : r|,r e hx[e] : t* 7 = Ai 


T T (Tn r„) heJen e\ ■ r v = first An 

>» 

second Ai 
>» 

A,; 


Brak 


T he : r"'' 7 = A 


T h(e) : (t"}" = A 


Esc 


T he : (t"P = A 


T h~e : t"'" = A 



Figure 5. Typing rules for a simple multi-stage language, along 
with a translation into generalized arrows. The rules and transla- 
tions are rendered in the rule/syntax/semantics table style of [? , 
Tables 3,5,9]. Note that contexts are represented as a binary tree 
rather than a list. An explanation of the rules can be found in Sec- 
tion 3.2. 



Definition pow : E V := 
letrec pow := \\ n => \\ x => 

If (Eeq V) [ 'n ; (Ezero V) ] 

Then < [Eone V] > 

Else <[(Emult V) [ ~~'x ; 

(~~ (Cpow) [ (Eminus V) [ 'n ; 
(Eone V)] ; <x ])) ] ]> 

in 'pow. 

Eval compute in (translate (pow_hastype _ n) ) . 
letrec x := \\ xO => \\ xl => 
If (first CxO) 

»> second ((first ga_true »> second id) 
»> id)) 

»> ga_true 
Then ga_true 

Else (copy »> (first copy »> (swap »> 

ga_true ['xl; copy >» (first copy >» 
(swap »> (drop »> id) [(first ((first 
CxO) »> second ((first ga_true »> 
second id) »> id)) »> ga_true) »> 
second ((first Cxi) >» second id) »> 
id)) »> Cx); drop »> id]))]))) 

in Cx) 

Figure 6. The pow function's abstract syntax tree and the result of 
running the translate procedure corresponding to the rightmost 
column of Figure 5 on it. Note that the resulting abstract syntax 
tree does not contain any brackets or escapes; they have all been 
translated to equivalent GArrow operations. 

system can determine if a function application is fully saturated. 
This is achieved via the firstClass(r, ff) hypothesis in App , which 
prevents any function application from producing a non-first-class 
value via unsaturated application. 

The App n+1 rule handles n-ary application for n>l. The first 
hypothesis is standard; the second ensures that a function is never 
applied to a non-first-class value; the third is standard and the fourth 
can be thought of as a recursive appeal to App n . Note that this rule 
does not assume that the three subderivations take place under the 
same context. In fact, they must take place under separate contexts; 
this will matter if Contr is removed. 

The Brak and Esc rules are standard, copied from [? ]. Briefly, they 
prevent one piece of code from being spliced into another using 
the ~e construct unless both pieces of code are of the same depth 
(number of surrounding brackets minus number of surrounding 
escapes is the same) and their level names are the same. The latter 
point will matter once a type is introduced for closed code in 
Section 4.7. 



4. The Translation 

The translation from multi-stage programs to generalized arrows 
is given by the rightmost column of Figure 5, and is formalized 
by the function translate in GArrow. v. Note that the translation 
operates on proofs ofwell-typedness rather than expressions. 

The accompanying Coq formalization in GArrow . v includes an in- 
ductive type representing each of the productions in Figure 4, using 
a PHOAS [? ] representation for expressions. Also included is an 
inductive type HasType of typing derivations under the rules of 
Figure 5, and a procedure translate, which produces a GArrow 
expression by structural recursion on a HasType proof. An abstract 
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syntax tree for the pow function is also included, and a correspond- 
ing HasType for it. The result of applying the translation procedure 
to a proof tht the pow function is well-typed can be found in Fig- 
ure 6. 

Remark 5 The fact that the translation operates on proofs rather 
than abstract syntax trees has two curious practical consequences 
in the accompanying GArrow.v. The first is that HasType must 
belong to Set rather than Prop, because although its inhabitants 
are proofs their identities are not irrelevant. The second is that 
the unpleasant work of using the structural rules to re-arrange 
contexts is easily automated using tacticals and the Ltac scripting 
language 2 . 

The GArrow . v formalization covers all material up to this point; the 
remaining material is not included in the machine-checked portion 
of this paper except where explicitly stated otherwise. 

The remaining subsections will investigate possible object 
language features which might be added, and the corresponding 
translation of each feature into generalized arrows. Each of the 
following subsections is completely independent of the others; any 
combination of the rule sets can be unioned with the rule set of 
Figure 5 to produce an object language with that specific 
combination of features. 

4.1 Recursive Let Bindings in Specific Stages 

Figure 7 gives syntax, typing rules, and translation rules for the 
ability to permit recursion at specific levels and types. Note that the 
predicate recOk is parameterized over both the level fj and the type 
t x where the recursion occurs. This can be useful for: 

• Allowing recursion only at certain stages. For example, only in 
the metalanguage by adding the rule with no hypotheses and 
recOk(r, ■) as the conclusion. 

• Allowing recursion only at certain types. For example, allow- 
ing recursively-defined functions but not recursively-defined 
ground values at level fj by adding the rule with no hypotheses 
and recOk(r —5- r, fj) as the conclusion. 

If recursion is to be used at any stage other than the first, it is 
necessary for the GArrow to also be a GArrowLoop and implement 
the loop function of Figure 7. This operation must satisfy the laws 
shown in Figure 8, adapted from [? , Figure 7], These axioms first 
arose in work on traces on categories [? ], and were first applied to 
functional programming in the context of value-recursive monads 
[?]. 

4.2 Booleans and Branching 

Figure 9 gives grammar, typing rules, and translation rules for 
boolean values and branching. Note again that the conditional and 
branches of the if construct are typed under disjoint pieces of the 
combined Ti , V context rather than under a shared context. 

4.3 Cross-Stage Persistence 

Figure 10 gives the rules for cross-stage persistence (CSP). CSP 
is permitted only for fully-normalized values belonging to a non- 
function (ground) type; these types are distinguished by the reifi- 
able(r, fj) judgement. Appropriate inference rules must be added 
for whatever kinds of types (primitives, products, coproducts, etc) 



2 This turned out to be far easier than expected 



e :.— let x=e in e 
£ ::= recOk(r,77) | ... 



RULE 


SYNTAX 


SEMANTICS 


Rec 


recOk(r^, fj) 
x~.t x ; Fx \~e x '• t x 
x:tS , F e he : r'' 


= A x 


i:E ' ie r let x=e x - T 


first ( 




in e 


loop ( 

A, 

»> copy)) 
»> A e 



Class GArrowLoop ((**): Set->Set->Set) 
((->) :Set->Set->Set) 
( ga:GArrow (**) (->)) := 
loop : (a**c~>b**c) -> (a~>b) 



Figure 7. Typing Rules for Recursive let at Specific Stages. As- 
sumes additional judgements for those stages at which recursive 
let-bindings are permitted. 



loop (first h >» f) = h »> loop / 
loop (/ »> first h) = loop / »> h 

loop (loop /) = loop (cossa »> f »> assoc) 
second (loop /) = loop (assoc »> second f >» cossa) 



Figure 8. Laws for the loop function. These follow the laws of [? 
, Figure 7], with "Extension" and "Sliding" omitted. 

are in the system to ensure that reifiable(r, fj) is derivable for those 
types at which it is appropriate. 

4.4 Product Types in the Object Language 

Figure 1 1 gives rules for product types. 

The laws given are exactly those needed to ensure that the <*> 
operator induces a finite product (Definition 7) structure with \X = 
drop and Ajc = delta. FIXME: should the GArrow itself choose 
unit? 

Remark 6 Note that ** and eg) are not the same. The ** operator 
represents contexts, which are not first-class in the object language. 
The <g> operator represents products, which are first-class in the 
object language. 

Arrows do not make the distinction above, which is a source of 
limitations. For example, an Arrow for stream processors does not 
distinguish between a pair of streams and a stream of pairs; both 
are a*b~>c*d (which is a retract of (a~>c) * (b~>d) in the ab- 
sence of side effects). With G Arrows pairs of streams have type 
a**b~>c**d and streams of pairs have type ag)b~>c®d. In a syn- 
chronous dataflow environment these two concepts coincide; this 
explains why all existing literature on using Arrows for stream pro- 
cessing [? ? ] and digital circuits [? ? ] applies only to synchronous 
environments. Attempts to create Arrows for unrestricted Petri Nets 
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r ::= bool ... 

e ::= true | false if e then e else e . . . 


RULE 


SYNTAX SEMANTICS 


Bool 




firstClass(bool, ff) 


True 




T h true : hooY 1 


False 




T h false : bool 11 


If 


he 4 : bool' 7 = Ai 
T Ve t : = At 
T he e : r* 7 = A e 


r„rh p :r" = (first Ai) »> 

then e t (branch At A e ) 
else e e 



Class GArrowBool ((**): Set->Set->Set) 
((->) :Set->Set->Set) 
( ga:GArrow (**) (->)) := 
branch : (a~>b) -> (a~>b) -> ( (bool**a) ~>b) 



Figure 9. Typing Rules for booleans. 



e ::= °/.e | ... 

E ::= reifiable(r, (f],ff)) \ . . . 



RULE 


SYNTAX SEMANTICS 


CSP 


reifiable(r, ff) 

T he : r' 7 


T h'/.e : r"'" = reify e 



Class GArrowReify ( (**) :Set->Set->Set) 
((->) :Set->Set->Set) 
( ga:GArrow (**) (->)) := 
reify : (a->b) -> (a~>b) 
reif y_extensional : 
forall -CaHbHf :a->bMg}, 
(forall x, (f x)=(g x)) 
-> (reify f) — (reify g) 

Figure 10. Typing rules for cross-stage persistence (CSP). 
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[? ] are impeded by this limitation. The need to have distinct types 
for "stream of pairs" and "pair of streams" led the Fudgets library 
to co-opt the coproduct structure of the underlying type system to 
represent pairs of streams, which explains the anomoly that Pater- 
son notes [? , Section 5.1] in the type of the Fudgets loop function 
[?]• 

4.5 Coproduct Types in the Object Language 

Figure 12 gives the rules for coproduct types. The branch and 
bool of Section 4.2 can be seen as a restricted form of cjnerge 
and <+>. 

4.6 Afflne, Linear, and Ordered Types in the Object 
Language 

Affine types in the object language can be modeled by omitting 
copy (eliminating the Cont rule); linear types can be simulated 
by omitting copy and drop (eliminating the Weak rule). Ordered 
linear types [? ] can be imitated by omitting swap (eliminating the 
Exch rule). 

Remark 7 If swap is omitted, the definition of cossa is no longer 
redundant, and it must be defined separately. 

Typechecking and type inference for affine, linear, and ordered 
types is a complex topic. This paper does not attempt to address 
these questions; it takes the finished typing derivation as a starting 
point for the translation procedure. 

4.7 The eval Primitive 

The rules for eval (also called run) can be found in Figure 13. The 
eval primitive can only be used safely on closed code; the open 
and close primitives are needed to mark such regions [? ]. 

The GArrowEval class, which has a Prop index but no methods, 
has a close relationship to Haskell's runST, the strict state monad 
[? ] which has rank-2 type: 

runST : : (forall s. ST s a) -> a 

The runST function has this type in order to ensure that values 
returned by runST do not contain "dangling references" to the state 
index s. This effect is achieved by taking advantage of the fact that 
the introduction rule for e : (Va)r requires that a not appear in the 
type environment - it is a closedness condition, albeit upon types 
rather than values (no matter: parametricity supplies the linkage). 
This closedness condition on types and values closely paralells the 
closedness conditions in the hypothesis of the Close rule, which 
must be applied before eval. 

Theorem 2 The translation converts staged values of closed type 
(t d } to expressions of a rank-2 type parametric over the GArrow 
instance. 

Proof, in translation_of _closed_code_is_parametric 

in GArrow . v □ 



5. Examples 

5.1 Fxponentiation of Natural Numbers 

It is now time to return to the example program, pow, expressed 
using staging annotations: 
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r ::=t Qs> t ... 

e ::=f st e | snd e | (e, e) 



r ::=r fcB T ... 

e ::=inl e I inr e I case e of I L x -> e I R x -> e 



Class GArrowProd (g:GArrow G) 

( (<*>) : Set->Set->Set) 

unit : Set 



delta 
isol 
iso2 
lift 
id ~~ 
id ~~ 



a ~> a<*>a 
a<*>unit ~> a 
unit<*>a ~> a 

(a**b) ~>(c**d) -> (a<*>b) ~>(c<*>d) 
delta »> (lift (id *** drop)) »> isol 
delta »> (lift (drop *** id )) »> iso2 



RULE 


SYNTAX 


SEMANTICS 




firstClass(ri, ff) 




FCp rot J 


firstClass(r2, ff) 




firstClass(ri(g)r2, rf) 


Fst 


r he : (n ® Tif 


A 


T hf st e : if 


~~ lift(id**drop) 
»> isol »> A 


Snd 


The: (riOTa^ 


A 


T hsnd e : t$ 


— lift (drop**id) 
»> iso2 »> A 




^ he a : rf 


Aa 


Prod 


T 2 he 2 : r| 


A 2 


ri,r 2 h(ei,e 2 }:(Ti<g>T 2 )" 


lift ( 
first Ai 
»> 

second A 2 ) 



RULE 


SYNTAX 




SEMANTICS 




f i t-ct-t~ 1 Trr/ 

rirSI^IdSS^ 






FC CO p ror j 


firstClass( 


T2,rf) 




firstClass(ri 






InL 


1 re : r-j^ 




A 


T hinl e 




— isol >>> 

Xif ~t C id** codrop) 
>>> ^ 


InR 


T he : r| 




= A 


r hinr e 




= iso2 »> 

lif t (codrop**id) 
>» A 




To he : (ti 




= A 




T, a;:rf hei : 




= Ai 


CP 


T, a;:rj he 2 : 




= A 2 


r ,rh 

case 


eo of 


" lift ( 




1 L 


x-> ei 


first Ai »> 




1 R 


x-> e 2 


second A 2 ) >» codelta 



Class GArrowCoprod (g:GArrow G) 

((<+>) :Set->Set->Set) := 
void : Set (* the uninhabited type *) 

codrop : void ~> a 
codelta : a<+>a ~> a 
isol : a ~> a<+>void 
iso2 : a ~> void<+>a 

lift : (a**b)~>(c**d) -> (a<+>b) ~> (c<+>d) 

id — isol »> (lift (id *** codrop)) »> codelta 

id — iso2 >» (lift (codrop *** id )) >» codelta 



Figure 11. Product Types 



Figure 12. Coproduct Types 



pow n x = 
if n==0 
then <[ 1 ]> 

else <[ ~x * ~(pow (n-1) x) ]> 

Theorem 3 For any ff, there exists a typing derivation using the 
rules of Figures 5 and 9 for T h pow : Int->(lnt}-><[lnt}'' 
where T contains suitable type assumptions for 0, 1, (*), (-), and 
(==). 

Proof, in pow_hastype in GArrow . v □ 



5.2 BiArrows 

BiArrows are meant to model Arrows with a notion of inversion. 
They were introduced in [? ] and further examined in [? ]. Briefly, 



Class BiArrow ((->) :Set->Set->Set) 
(arrow: Arrow (~>)) := 



biarr 


(a->b) -> (b->a) -> 


(a~>b) 


inv 


a~>b -> b~>a 




pfO 


inv (biarr f f ' ) - 


— biarr f ' f 


pfl 


inv (inv f) - 


— f 


pf2 


inv (g »> f) - 


— (inv f) »> (inv 


pf3 


inv (arr f) - 


— (arr swap) 


pf4 


inv (first f) - 


— first (inv f) 



The BiArrow class adds a new constructor biarr, which is to 
be used in place of arr. It takes a pair of functions which are 
required to be mutual inverses. The inv function attempts to invert 
a BiArrow. 

Types belonging the class BiArrow consist of operations which 
might be invertible. Some BiArrow values are actually not invert- 
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r::= {r U } | ... 

e ::= open e | close e | eval e \ . . . 



RULE 


SYNTAX 


SEMANTICS 


Open 


T he : (r ^ 7 

X ¥ 


= A 


T hopene : (r"'}" 


= A 




t/ g FV(r,r?, r) 




Close 


r he : (r"'}" 


= A 


T hclose e : (r }" 


= A 


Eval 


T he : It* 3 }* 


= A 


F heval e : r* 7 


= eval A 



Class GArrowEval ((**): Set->Set->Set) 
((->): Set->Set->Set) 
( ga:GArrow (**) (->)) := 
(idx:Prop) := { >. 
eval : forall ((**): Set->Set->Set) 
((->) :Set->Set->Set) 
( ga:GArrow (**) (->)), 
(forall (idx:Prop), 

(GArrowEval (**) (~>) ga idx) -> (a~>b)) 
-> (a->b) . 

Figure 13. Rules for eval. 

ible, so the inv operation is only partial and may fail at runtime. 
The type system is not capable of ensuring that "well-typed pro- 
grams cannot go wrong" in this way. Unfortunately there is no way 
to fix this within the framework of Arrows, because the Arrow type 
class requires that arr be defined for arbitrary functions - even 
those like f st (the first projection of a tuple) which cannot possi- 
bly have an inverse. Moreover, the arr function is tightly woven in 
to the laws which prescribe the behavior of Arrows, so solving the 
problem is not as simple as replacing arr with biarr. 

However, one can create a GArrow which preserves invertibility. 
There are two possibilities, in fact: 

• Realize the GArrow drop method using the logging transla- 
tion of [? , Section 6], which implements tuple projection by 
concealing the non-projected coordinates rather than discarding 
them entirely. 

• Declare a superclass of GArrow which omits the drop function. 
This is not nearly as violent a change as attempting to remove 
arr from Arrow; the translation of Figure 5 remains intact for 
any derivation which does not use the Weak rule. As a result, 
object programs typeable under certain variants of linear logic 
remain translatable. 

5.3 Circuit Description 

Many researchers have investigated the use of functional program- 
ming languages to describe hardware circuits [?????]. The allure 
is strong: combinational circuits and pure functions have much in 
common. However, in order to create usable circuits one must allow 
for sharing and feedback, and this is where the similarities end. 



Pure functional languages which represent circuit nodes as first- 
class language values must add an impurity, observable sharing 
[? ], to the language in order to preserve sharing information and 
permit introspection on circuits with feedback. This impurity is in- 
compatible with optimizations present in many compilers for pure 
functional languages and considerably complicates the semantics 
of the language. The alternative is to represent circuits using a 
value-recursive monad [? ] or Arrow; this avoids the pitfalls of 
observable sharing but requires that circuits be constructed in an 
object language which is completely different from the functional 
metalanguage - a choice which dilutes the benefits sought. 

With the translation from staging annotations to GArrows, program- 
mers can write circuits and circuit generators with a single set of 
binding, scoping, abstraction, and application mechanisms. 



6. Categorical Perspective 

The time has come to make good on the promise of the paper's 
subtitle. Technically what will be exhibited in this section is an 
equivalence of categories, but - like every equivalence - this will 
give an isomorphism of skeletons. 

In addition to abstract theorems involving categories, most subsec- 
tions of this section will include an example involving a category O 
whose objects are the types of some object programming language 
(pick your favorite side-effect free language) and whose morphisms 
are the functions of that language. 

Definition 1 ([? , Definition 2.7]) An object 1 of a category C is 
the terminal object if there is exactly one morphism into 1 from 
every other object. This morphism will be written \A : A— 

Definition 2 ([? , 3.2]) A binoidal category is a category C 
given with a pair of bifunctors — x— : CxC — > C and — x — : 
CxC — > C such that for all objects A, B of C it is the case that 
AkB = AxB, which is also written A®B. 

Definition 3 ([? , 3.3]) A morphism / for which it is the case that 
f«g — f x g for all g is called a central morphism. 

Binoidal categories are generally used to model computations in 
which evaluation order is significant. The fact that the two bifunc- 
tors agree on objects reflects the fact that type systems do not track 
which coordinate of a tuple was computed first. The fact that the 
bifunctors may disagree on morphisms reflects the fact that evalu- 
ating the left coordinate first may yield a different result than eval- 
uating the right coordinate first. Central maps model computations 
which are pure and therefore commute (in time) with all others. 
Note that for morphisms / and g the expression f®g is not well- 
defined unless at least one of / or g is central. 

Definition 4 ([? , 3.5]) A premonoidal category is a binoidal cat- 
egory with an object / such that A®{B®C) = {A®B)®C and 
X®I = X = I®X for all objects X subject to the coherence 
conditions of [? , pi 62]. A strict premonoidal category is a pre- 
monoidal category in which the above isomorphisms are identity 
maps. A premonoidal functor is a functor between premonoidal cat- 
egories which preserves this structure. 

Definition 5 A symmetric premonoidal category is a category in 
which A(&B = B®A and the mediating isomorphism is its own 
inverse. 

Definition 6 A monoidal category is a premonoidal category in 
which every map is central. 
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Note that a category may be monoidal in more than one way: there 
may be multiple bifunctors that satisfy the properties above. For 
example Sets, the category of sets and functions, is monoidal under 
not only cartesian product but disjoint union as well. The same 
applies to binoidality and premonoidality. 

Definition 7 A finite product category is a monoidal category in 
which I = 1 is a terminal object along with a morphism Ax : 
X— >X(&X for each object X such that the following diagram 
commutes: 

\X <g> id x 
1®X < X®X 




SLY 



X 



l(g>X 



FIXME: and is equal to the identity - need another branch A finite 
product functor is a functor between finite product categories which 
preserves this structure. 

In a finite product category the monoidal functor will be written x 
rather than Cg> to emphasize this additional structure. Note that 1 is 
the 0-ary product; zero is considered finite in this paper. 



Definition 8 ([? 

indexed category 
C and a functor H 1 : 
C in such a way that 
thenC S D 1 . 



Definition B1.2 

,(-) 



1(a)]) For C a category, a C- 
assigns a category D A to each object A of 
to each morphism / : X — > Y of 
J) 9 ° f . If C has a terminal object 1, 



Definition 9 ([? , Definition B1.2.1(b)]) An C-indexed functor 
p(-) . p(-) flj(-) assigns to each object A of C a functor 
F A : D A ->■ E A and to each morphism / : X -> Y a natural 
isomorphism : (F y aW) = (E-^ oF x ) allowing the following 



diagram to commute up to isomorphism of functors: 




Definition 10 For a category C with monoidal bifunctor 
( — )®(— )> a ®-exponential is a bifunctor (—)=>( — ) such that for 
each object B of C, the functor — ) is right adjoint to the 
functor (— 



An ( 



-exponential induces the following isomorphism of Horn-sets: 

A®B -> C 



A -+B 



C 



Definition 11 A cartesian closed category is a finite product 
category with a x -exponential. 

Remark 8 The definition of exponential is usually stated in a form 
specific to cartesian products. The more general definition above 
will allow investigation of exponentials over monoidal structure 
which is not necessarily a cartesian product. 

6.1 Polynomial Categories 

Most algebraists are familiar with the construction whereby one 
passes from a ring R to the ring R[x] of polynomials with one 



indeterminate and coefficients from R. A similar construction is 
possible with categories. 

Definition 12 (Provisional) Given a category C with a terminal 
object 1, and some object B of C, let the polynomial category over 
C in B, written C[a;:B], be the free category obtained by adjoining 
to C a new morphism x : 1— >B and closing under composition 
and products of morphisms. The morphisms of C[x:_B] are called 
polynomials over C in B. [? , Definition 2.5] 

Like the free group on a set, this "free category obtained by adjoin- 
ing a new morphism" can be understood intuitively as the category 
including x:l— >B while introducing as few new morphisms and 
satisfying as few new identities as possible. Terms with free vari- 
ables in them are best understood as morphisms in a polynomial cat- 
egory, and variable-binding operators as functors from the polyno- 
mial category back into the host category. This gives some semantic 
weight to the notion of a "term definable in terms of some hypothet- 
ical of type B" - these are exactly the morphisms of C[i:B]. 

This paper will generally represent polynomial morphisms (except 
for the indeterminate x) using lower-case letters with a superscript, 
such as f B , as a reminder that f B belongs to C[a;:B] rather than 
C. 

Definition 13 (Provisional) The weakening functor of a category 
C assigns to each object B of C a functor C !s : C— ¥<C[x:B] from 
C to the polynomial over C in B such that C !s is the inclusion 
functor when C is regarded as a subcategory of C[x:B]. 

Remark 9 If it happens that C is a finite product category, one can 
construct C[x:B] and the weakening functor explicitly: the weak- 
ening functor sends each object A to BxA and each morphism / 
to ld_ex/. C[x:B] is the subcategory of C which is the range of 
this functor. However, if C has a weaker monoidal structure (per- 
haps only premonoidal), or none at all, the notion of polynomial 
category is not definable in this manner. 

A slightly more rigorous formulation, adapted from [? , Remark 
2.6], can be given in terms of indexed categories and universal 
properties: 

Definition 14 (Official) For C a category with a terminal object 
1, a polynomial category C[x:—] is a C-indexed category such that 
for every object B, functor G:C— s>B and d:l— >G(B) there exists a 
unique functor [x :=d] G (—):C[x:B]^I$ such that [x :=d] G (x) — d 



and [x:=d] G oC ]B = G. 



C[x:B] 




3[s:=d] G (-) 



The functor C' is called the weakening functor at B. 

Intuitively, this definition says that for a functor sending C to D one 
can choose any morphism d with codomain in the range of G and 



factor the weakening functor C' 
a way that x is sent to d. 



through the given functor in such 



Example. Recall that each object of O represents a type in the ob- 
ject programming language. If we pick some type T, then 0[x:T] 
will be a new category, with an object for every type of O. The 
objects of this new category represent expressions in our object 
language having a free variable x of type T. So, for example, if 
Int is a type, then 0[x:lnt] will be the category of expressions 
with a free variable x of type Int, and if String is another type, 
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b : 1-KB 



f B : A -»• C 



lifU(&) : A^4®B K,x:B.f B : A®B->C 
( K x:B.f B ) o lift A (6) = [z:=6] G (/) 
Figure 14. Rules of the K-calculus, from [? ] 



a morphism in a contextually complete category. The K-calculus 
is a syntax for the internal language of a contextually complete 
category in the same way that A-calculus is a syntax for the internal 
language of a cartesian closed category. 

6.3 Reification 



there will be an object Int (String) corresponding to String in 
0[a;:lnt] representing object language expressions having overall 
type String and a free variable x of type Int. 

If we pick some function / in our object language, where / is a 
function that takes an Int and returns a String, there will be some 
/ : Int — > String in O. Now recall that polynomial categories are 
just a particular kind of indexed category, and indexed categories 
must assign a functor to each morphism (Definition 9). The polyno- 
mial category assigns / a functor O f : 0[x:String] —¥ 0[x:lnt]. 
Note that the order of the argument and return type has changed! 
This functor takes a term with a free variable x of type String and 
yields a term with a free variable x of type Int. How does it do 
this? By substituting f(x) for x. 

6.2 Contextual Completeness 

Definition 15 ([? ]) A polynomial category is said to be contextu- 
ally complete if its weakening functors each have a left adjoint. 

The left adjoint functor will be written {-)®B H C !B . The unit 
of the adjunction ??-®b : (— )— >(— )®B has the property that for 
every f B :A-^C in C[x:B] there exists a f:A(g>B~>C in C such 
that f B = C !B (/) o VA(SB . Writing \x:B.f B for / gives: 

f = C W (\x:B.f B )°r, A ® B 

Remark 10 In [? ], an explicit definition of Xf B is given for any 
contextually complete category which also has finite products; the 
definition assumes the monoidal structure of C has projection and 
morphism-tupling. The construction bears much similarity to typed 
combinator conversion, but - as that author notes - is completely 
first-order (in contrast to Curry's [? ] combinator conversion) and 
avoids introducing divergent terms (in contrast to Schoenfinkels [? 
])■ 

Now, select some morphism 6:1— >B and generate the functor 
[x:=6] ld (— ) by Definition 14 corresponding to the identity functor 
on C. It has the following property: 

f B = C !B (Ax/ :B.f B )o VA ® B 

x:=b] ,d (f B ) = [x:=b] k, (C W (\x:B.f B )or, Ae>B ) 

x:=b] ld (/ B ) = [x:=b]' A {e B {\x:B.f B )) o [x :=6] ld ( VA0B ) 

x:=b] ,d (f B ) = (([x:=b] ld oC !B )(Ax:B./ B )) o [x:-b] u (r,A 9B ) 

x:=b] ,d (f B ) = \d c (Xx:B.f B ) o [x :=b] ,d ( VA<8>B ) 

x:=b] ,d (f B ) = (\x:B.f B ) o [x:=b] U (r, Ae)B ) 

The last two steps exploit the universal property [x:=6] ld oC !B = 
Idc of the weakening functor (Definition 14). 

Following [? ], abbreviate I ift^i (6) = [x :=6] ld (r/ A ® B ). The above 
definitions and derivations give the three rules of the /-c-calculus 
introduced in [? ] to isolate the "first order" element of the lambda 
calculus. These rules are shown in Figure 14. 

These inference rules define the syntax of the K-calculus, and the 
derivation shows that any syntactical term of the calculus identifies 



Having reviewed polynomial categories and the standard definition 
of contextual completeness, how can one reason about programs 
which manipulate other programs with free variables? Answer: 
reification of categories. 

Just as polynomial categories were a particular kind of indexed 
category, reification of one category in another is a particular kind 
of indexed functor between their polynomial categories. 



Definition 16 If 0[x:-] and : 
and (-}:0 -> M is a functor, 
indexed functor 

/f.\(-) . or,-. 



[x:—] are polynomial categories 
I reifies O via (•} if there is an 

] -> M[z:(-}] 



such that for each object B of O the following diagram commutes 
up to isomorphism of functors: 



\x:B] 



U[x:{B}} 



1(B) 



Remark 11 Two technicalities must be noted, but can be skipped 
on a first reading. First, the above abuses notation somewhat: (•} is 
not strictly the same thing as the former is a non-indexed 

functor, the latter an O-indexed functor. The notation is recycled 
because the two have similar effect. Second, M[a;:— ] is not the 
same thing asM[i:{-}]; the latter is the indexed category resulting 
from reindexing the former along the functor {■}. Similar notation 
was chosen in order to de-emphasize the least important details. 

Example. Let M be a category whose objects are the types of the 
metalanguage and whose morphisms are its functions; this means 
that M[a;:— ] has an object for every type of the metalanguage. The 
functor (•} : O — > M must assign a metalanguage type to each 
object language type, so in a certain sense the metalanguage has a 
copy of the object language type system within it. Reindexing the 
polynomial category M[a;:— ] by (•} to form M[a;:(— }] essentially 
means focusing attention on the subset of our metalanguage whose 
free variable types and return types are all drawn from this copy of 
the object language's types. Now, consider the properties bestowed 
by the indexed functor. For any object BeO, the component of 
the indexed functor will give a non-indexed functor 

(-} B : <0>[x:-] -> M[z:{-}] 

What does this functor do? The last part of Definition 16 requires 
that the functor supplied for each object has essentially the same 
behavior as the (■} functor combined with M[a;:— ]'s weakening 
functor M !B . So if X is an object of O and <0 ]B (X) is the result of 
weakening X into 0[x:B], then reifying this give the same thing as 
weakening {X} into M[a;:(B}]: 

(0 !B (X)} B ^M !(B) ((A» 

This is why similar notation was chosen for (■} and (-}' - '. Defi- 
nition 9 says that for a morphism f:X—¥Y in O, there will be a 
functor O 1 : 0[x:Y\^0[x:X]. It was determined earlier that this 
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functor has the effect of substituting f(x) for a; in a term that has 
a free variable x. Moving now to the reification functor, it is clear 
that {f} B : M[x:{Y}]-)-M[x:{X}]. But what does this functor do? 

Recall that an indexed functor also assigns a natural isomorphism to 
every morphism. Suppose B is an object in O, and X, Y are objects 
in <0[x:B]. Then by Definition 9, our reification functor must assign 
to each / :I->7a natural isomorphism 

{-} f : (M m o {-} Y ) 9£ ({-} X o <O f ) 

This is the key to understanding what {f} B does. In prose, the 
above isomorphism says that applying and then reifying is the 
same as reifying first and then applying (/}. So we know that (/} 
has the effect of substituting under the brackets, which is exactly 
the operation needed in order to manipulate object-language pro- 
grams. 

To sum up, starting from a given functor (•} : O — > M, asking 
for a family of functors, one {-} B for each B 6 O does not say 
much: these could all be trivial functors which send every object 
to a single object and every morphism to its identity. Requiring 
that this family of functors forms an indexed functor is what forces 
to have the "substitution under brackets" behavior. The 
natural isomorphism required by Definition 9 turns into precisely 
the condition which characterizes the code-splicing behavior of 
staging annotations. 

6.4 Contemplation 

Definition 17 A category M contemplates a category O if M rei- 
fies O and M is contextually complete. A category is contempla- 
tively complete if it contemplates itself. 

Contemplation is the categorical property which best models multi- 
stage type systems; Contemplative completeness is the categori- 
cal property which best models homogeneous multi-stage type sys- 
tems. 

Theorem 4 (Staging and Contemplation) The category whose ob- 
jects are the types of Figure 5 and whose morphisms are the func- 
tions definable in that system forms a contemplatively complete 
category. 

Proof. Establish a category M with an object for each type of the 
language and for each object B freely generate the polynomial cat- 
egory over M in B. The inference rules Lam, App and App n+1 
define the operations of the K-calculus and satisfy the laws of Fig- 
ure 14, so contextual closure is straightforward. The syntactical op- 
eration which sends an expression e having free variable x of type 
B to the expression {e[x : = (~x)]} is an indexed functor (with B be- 
ing the index) whose action on types sends M ! B ( A) to M ! ( (A) ) . 
This indexed functor is the reification functor with the required 
properties. □ 

Definition 18 ([? ]) For a monoidal category C and endofunctor 
F : C — > C, the endofunctor has functorial strength if for every 
pair of objects A, B of C there is a morphism satisfying certain 
coherence conditions: 

F a ,b : F{A)®B ->■ F{A®B) 

Definition 19 A contemplatively complete category has enriched 
contemplation if the coordinates of the reification functor all have 
strength. 

Strengths on the reification functor give the ability to perform cross- 
stage persistence. The morphism : (1}®j4 — ¥ {1 ® ^4} = 
A — > {A} provides the required transition. 



6.5 K-Categories and Freyd Categories 

Definition 20 ([? , Definition 11]) A K-category consists of a finite 
product category C and a C-indexed category H such that: 

1. For each object A of C, H A has the same objects as C, and H 1 
is the identity on objects. 

2. For each projection morphism ty : Bx A^-B of C, H n has a 
left adjoint (-)xi 

3. For each morphism / : B — s> B' , the natural transformation 
4>: ((-)8-B)off /xidA -> H s o{[-)®B') induced by the ad- 
jointness in the previous bullet point is in fact an isomorphism. 

Theorem 5 Categories with enriched contemplation and finite 
products are in bijective correspondence with ^-categories. 

Proof. Given a category M with enriched contemplation and finite 
products, M[a;:— ] is the requisite M-indexed category, (1) each 
M[a:S] has the same objects as M and the weakening functor M !s 
is identity-on-objects (Definition 14), (2) because M is contempla- 
tive it is contextually complete (Definition 17), so the weakening 
M"" of any projection morphism n has left adjoint (Definition 15), 
and (3) the natural isomorphism imposed by the indexed reification 
functor (Definition 16) supplies the requisite <j>. □ 

Definition 21 ([? , A.4]) A Freyd Category is a category C with 
finite products, a symmetric premonoidal category K, and an 
identity-on-objects strict symmetric premonoidal functor 

J : C -> K. 

Theorem 6 ([? , Theorems 13 and 14]) Freyd Categories and k- 
categories and are in bijective correspondence. 

Theorem 7 (The Stages-Arrows Isomorphism) Categories with 
enriched contemplation and finite products are in bijective corre- 
spondence with Freyd categories. 

Proof. By transitivity of bijective correspondence. □ 

Remark 12 The proof shown for Theorem 7 is clearly trivial once 
the appropriate context has been set up. The main contribution of 
this section is not a one-line proof, but rather the identification 
and definition of enriched contemplation as the appropriate crite- 
rion. Specifically, enriched contemplation is a strong enough con- 
dition to make the proof of bijective correspondence go through 
(almost effortlessly), but still weak enough that a large class of 
stage-annotated metaprogramming languages constitute categories 
with enriched contemplation. Furthermore, enriched contemplation 
is not even quite so important as the weaker forms it suggests. If cat- 
egories with enriched contemplation and finite products are in bijec- 
tive correspondence with Freyd categories, it is natural to ask what 
is in bijective correspondence with obvious weakenings such as 
monoidal categories with enriched contemplation, premonoidal cat- 
egories with enriched contemplation, categories with non-enriched 
contemplation, and categories which reify categories besides them- 
selves. Generalized arrows subsume all of these. So while Theo- 
rem 7 may not be surprising or unlikely, the connection it estab- 
lishes justifies the generalization. 

7. Future Work 

7.1 Polymorphism and Inference 

The presentation in this paper did not cover either type polymor- 
phism or inference; these will be necessary for a production-quality 
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id_left 


: forall 


(A B:Set) (f:A~>B), 


id »> f 


~~ f 




id_right 


: forall 


(A B:Set) (f :A~>B) , 


f 


— f »> id 




comp_assoc 


: forall 


(ABC D:Set)(f :A~>B)(g 


:B~>C) (h:C~>D) , (f »> g) »> h 


— f »> (g »> h) 




f irst_law 


: forall 


(ABC D:Set)(f :A~>B)(g 


:B~>C) , first (f »> g) 


— first (c:=D) f »> 


first g 


law5 


: forall 


(A B C:Set) (f :A~>B) , 


first (first f) »> assoc 


— assoc(c:=C) (b:=B) 


»> first f 


law6 


: forall 


(A B C:Set), 


cossa 


— swap »> assoc (b: 


:=B) »> swap 


law7 


: forall 


(A B C:Set)(f :A~>B), 


first f »> drop 


— drop (b:=B) »> f 




law8 


: forall 


(A B:Set) , 


swap (b:=B)(a:=A) »> swap 


~~ id 




law9 


: forall 


(A B:Set) , 


copy »> swap 


— copy (a:=A) 




law_assoc 


: forall 


(A B C:Set), 


assoc (c:=C) (b:=B) (a:=A) >>> cossa 


~~ id 




law_cossa 


: forall 


(A B C:Set), 


cossa (c:=C) (b:=B) (a:=A) >>> assoc 


~~ id 





Figure 15. GArrow laws of Figure 3, rendered as Coq propositions to be satisfied by any Instance of GArrow 



system. This will require extending the grammar for types: 

a :■— type variables 

t ::= ... | a | Va.r 

The firstClass(r, ff), reifiable(r, 17), and recOk(r, 77) judgements 
present a small complication for polymorphism; when attempting 
to assign a polymorphic type to an expression, the typical rule used 
[? ] is something similar to: 

a £ FV(ri,r 2 , T 2 ,r?) 
ri h ei : rf 
T 2 ,x : (Va.Ti)^ h e 2 : 

Ti,r2 h let x=e\ in e 2 : 

In this arrangement, the type inference procedure may find itself 
confronted with the need to prove judgements such as 
firstClass(a, ff) where a is a type variable. The solution to this 
situation is to introduce qualified types [? ], gathering a list of 
constraints imposed on each type variable and annotating type 
quantifiers with these constraints, creating types such as 
Va.firstClass(a, ff) r. 

Level polymorphism will also be necessary for a production-quality 
system. The algorithm described in [? ] appears to be the most 
appropriate. Among the changes required will be extending the 
grammar for types: 

T ::= . . . | V»?.t 

and adding a typing rule to propagate the firstClass(r, ff) judge- 
ment across level quantifiers: 

»/£FV(t,77) 
firstClass(r[r;:=? ? / ], ff) ^ 

firstClass(Vr?.T, ff) v 
7.2 Dependent Types 

The characterization of staging annotations as an indexed functor 
among polynomial categories gives a category-theoretic foundation 
to multi-stage programming. In this context, dependent types are 
understood as the objects of locally cartesian closed categories [? 
, Definition 9.19]. This should provide a straightforward way to 
investigate multi-stage programming at all corners of the lambda- 
cube [? ], perhaps leading to a sound multi-stage Calculus of 
Constructions [? ]. 
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